home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 652 < prev    next >
Internet Message Format  |  1994-08-27  |  5KB
  1. Date: Wed, 15 Jun 1994 22:28:59 -0400 (EDT)
  2. From: Timothy Miller <millert@undergrad.csee.usf.edu>
  3. Subject: Re: The HELP key
  4. To: gem-list@world.std.com
  5. In-Reply-To: <P9472@IZ.maus.de>
  6. Message-Id: <Pine.3.87.9406152259.E29583-0100000@undergrad>
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10.  
  11. Neil:
  12. -----------------
  13. As there are only two modifiers - Control and Shift-Control - we only 
  14. need to
  15. use one the one character to denote what modifier is needed... perhaps the
  16. degree symbol (ASCII 248) to denot Control, and the filled degree symbol
  17. (ASCII 249) to denote Shift-Control.... I have also checked these symbols 
  18. with
  19. the standard font and the Monaco font with NVDI and they are the same in 
  20. each.
  21. -----------------
  22.  
  23. Alt!  You forgot Alt!  :)  Oh, and Shift-Alt, I guess.  Well, it MIGHT be 
  24. a good idea to use new symbols, but certainly not two symbols that look 
  25. ANYTHING alike.  How about Kof (204) for Control, Alef (194) for Alt, and 
  26. Samekh (208) for Shift?  Perhaps, perhaps not.  I think it may be unwise 
  27. to change to new symbols, since everyone knows what they mean, and it 
  28. would take a while for them to learn what the symbols mean.  Back when I 
  29. first encountered these symbols, ^ for control is something that I'd used 
  30. before, the up-arrow was relatively obvious for shift, and I had to GUESS 
  31. at what the symbol for Alt meant.  Once I learned them, they stuck, and 
  32. I'm comfortable with them.  I'm curious to see what others have to say.
  33.  
  34.  
  35. Nolte:
  36. ------------------
  37. Waldi Ravens:
  38. >If a user wants to have ^Z for quitting apllications,
  39. If a user doesn't want to stick to the standard, then tell him to buy a PC
  40. or whatever. A standard is a set of rules. You don't make rules and then
  41. let people decide whether or not they wan't to stick to them. Rules are
  42. made for everybody to stick to them. Period.
  43. Jesus, why in the world are we trying to establish a standard, if we can't
  44. get the user to stick to it? If you allow the user to change the
  45. shortcuts, you'll get a lot of programmers to use this as an excuse for
  46. not sticking to the standard. And then you might as well forget about the
  47. standard in the first place.
  48. ------------------
  49. Yes, yes.  I quite agree.  Make the standard a good one, make it work, 
  50. make it bullet-proof, and then tell people to USE it.  No excuses, except 
  51. in cases of danger.
  52.  
  53.  
  54. Another comment... Assigning Select-All to Shift-Ctrl-A is good.  
  55. However, I do not agree that Hide Block (deselect all) should be assigned 
  56. to Ctrl-A.  Anything that is assigned to Ctrl-A should have no noticable 
  57. affect, like "redraw window".  If you're using the Block==Big-Cursor 
  58. system AND you're touch-typing the problem with Ctrl-A being too easy to 
  59. hit no longer holds since there would be no block to deselect.  However, 
  60. in other situations, it could be annoying to lose your selection 
  61. (although far from fatal).
  62.  
  63. Select All    - Shift-Ctrl-A
  64. Redraw window - Ctrl-A
  65. Hide Block    - Depends.  It's a moot point in Big-Cursor block systems.
  66.  
  67. Oh, and I have seen Ctrl-G mean Goto before, and I am in support of that 
  68. because I feel that the search and replace should be simplified.  I've 
  69. seen some before that I agree with, but off the top of my head, I get this:
  70.  
  71. Find...           - Shift-Ctrl-F
  72. Replace...        - Shift-Ctrl-R
  73. Find next/prev    - Ctrl-F
  74. Replace next/prev - Ctrl-R
  75.  
  76. The direction is set in the dialog.  This also makes it easier to hit the 
  77. 'next/prev' option than to call up the dialog for the operation.  I might 
  78. also be inclined to simplify it further and put the selection of Find or 
  79. Replace into the dialog.  The exit button would determine which it is and 
  80. another key would repeat it, whether it was find or replace.  In this 
  81. case, you'd get the following:
  82.  
  83. Find/Replace...      - Ctrl-F
  84. Repeat F/R next/prev - Ctrl-Something.  (POSSIBLY G, maybe R)
  85.  
  86. This is an implementation problem, not something that should necessarily 
  87. be GOVERNED by the standard.  Perhaps it would be best to put all the 
  88. options in the standard and let the programmer decide which he actually 
  89. wants to use.  Then you'd get:
  90.  
  91. Find(/Replace)...            - Ctrl-F
  92. Replace...                   - Ctrl-R
  93. Find(/Replace) next/prev     - Shift-Ctrl-F
  94. Replace next                 - Shift-Ctrl-R
  95. Repeat F/R next/prev         - Ctrl-Something
  96.  
  97. The problem goes on and on.  Perhaps we should say how we prefer it and 
  98. leave the rest entirely to the progammer.  Tell him which ones are 
  99. 'common' (not 'standard'), and tell him which ones are unassigned (IN 
  100. THAT CATEGORY) so he can do what he wants with them.
  101.  
  102. It also might be prudent to DE-assign some things already in the standard 
  103. to make room for some more productive functions to put in those place.  
  104. But I don't think that Find/Replace is quite that important.  I will, on 
  105. rare occation, search a text file for something (most often, the first or 
  106. only occurence), or I will globally replace something.  When editing 
  107. articles, I would often have to replace all occurences of ".  " with
  108. ". " to comply with formatting rules of Calamus. 
  109.  
  110.